1. Field of the Invention
The present invention generally relates to a method and system for providing optimization process repeatability in on-demand computing environments, and more particularly to a method and system for removing variability in an optimization model instance.
The present invention provides an innovative data transformation technique that enables repeatability of optimization processes, and a service based architecture analytical framework that allows the data transformer to be easily reused, updated, and extended to the user or a plurality of users. An exemplary problem solved by the invention, e.g., optimization process repeatability, has not been addressed by application vendors or off-the-shelf solver vendors.
2. Description of the Related Art
FIG. 1 illustrates a typical optimization system 100. Such processes are concerned with those business optimization problems that can be formulated as mathematical programming models solvable by off-the-shelf solvers such as CPLEX.
As illustrated in FIGS. 1 and 2, in conventional optimization systems 100 and 200, when a business user initiates an optimization run using a specific logical data model 1, the data representation component 2 creates a physical representation (i.e., a physical data instance 3) of the logical data model 1 and feeds the physical data instance 3 into the optimization application 5. In the optimization application 5, the physical data instance 3 is combined (e.g., using combiner 12) with an optimization model 11 to yield an optimization model instance that can be solved by the underlying off-the-shelf solver 7 to determine an optimization result 4. The off-the-shelf solver 7 runs on top of an operating system 8, which runs on top of hardware 9.
A first vendor (e.g., Vendor A), or another vendor, generally controls the data representation component 2 and access to the logical data models 1. On the other hand, a second vendor (e.g., a different vendor, such as Vendor B, which may be a data integration vendor) generally is responsible for the optimization application 5.
With respect to the data representation component 2, logical data models 1 (e.g., raw data) are subjected to filtering and transformation by this component in order to be converted into a format that can be used by the optimization application (for example, a list of fires and parameters about each fire, a list of fire-fighting resources that can be applied to each fire, cost of resources etc.), each stored in a programming language specific data structure.
In the conventional methods, given the same logical data model 1, this data representation component 2 will often generate a different physical data instance 3a-3n each time it is invoked. For example, when Vendor B (e.g., data integration vendor) implements the data representation component, they use HashMap, a common data structure in modern programming languages, to store the list of fires. However, because of the fundamental way a HashMap is implemented, the same list of fires often end up with different HashMap representations, during different runs of the data transformation component 2, in terms of the natural order in which the fires appear in the HashMap.
For business consistency purposes and from a business user's point of view, given the same logical data model 1 and similar hardware/software computing environments 6, the same optimization result is desirable, and indeed, ideally would be expected because “optimization repeatability” is an important factor that impacts customer acceptance.
However, the conventional methods have not been capable of providing such desirable optimization repeatability, which may lead to business decisions that cannot be sustained over a period of time, which may in turn lead to loss of business value for the enterprise.